There is increasing concern surrounding security of communications and transactions performed using computer systems and data networks. These concerns include exposure of data, system compromise due to software attack and lack of user trust.
Various mechanisms and technologies have been developed to address these concerns, although mechanisms intended to address different problems are not always compatible and complementary, resulting in conflicts and/or, new vulnerabilities.
A recent development is the provision of data processing system (referred to as a “platform”) that is “trusted”—that is, can be relied on by the user to behave in a predictable manner and that subversion by another will at the least be apparent. Trusted computing system specifications have been developed by the Trusted Computing Platform Alliance and the Trusted computing group among others. In the Trusted Computing Group specification (found at www.trustedcomputing.org) and in the associated book “Trusted Computing Platforms: TCPA Technology in Context”, edited by Siani Pearson and published July 2002 by Prentice Hall PTR (the contents of which are incorporated by reference herein to the extent permissible by law), there is described an approach to trusted computing which employs a trusted coprocessor (both physically and logically protected from subversion) to assure a user of data processing system including or associated with the trusted coprocessor that it is performing in a predictable and unsubverted manner. In addition or alternatively, a compartmentalised operating system may be used (typically by operating in a compartmentalised manner such that processes run in separated computing environments that have strictly controlled interaction with other computing environments—such an arrangement is discussed in, for example, the applicants' patent application published as EP1182557).
One advantage of using a trusted platform is that other parties will be ready to interact with the trusted platform if they have a means of assuring that it conforms to an agreed standard and will therefore behave in an expected manner. Such an other party may be a Remote Service Provider (RSP) who is able to provide a service to a platform, but may be unwilling to provide this service if it cannot be assured that the platform receiving the service is indeed trusted.
An RSP may be, for example, an enterprise server that provides services to remote platforms. The service is only provided to remote platform if the RSP can confirm that it is in a secure state (for example, verify that it was not stolen). In a different example, the RSP might provide digital content, such as music or video, to remote players. The RSP only provides the content if it can verify that the remote player is in a secure state, and does not enable, for example, illegitimate duplication of the content.
A trusted platform typically includes one or more trusted platform components (trusted components are described here as Trusted Platform Modules or TPMs) that may be a logical (software) or a physical (hardware) component within the platform. Whilst the trustworthiness of a TPM may be measured relative to a standard such as that of the Trusted Computing Group, it is typically be the manufacturer of the TPM vouching (and often providing a digital certificate certifying) for the trustworthiness of its module that imparts the trust. It can be assumed that an RSP will trust at least some manufacturers of TPMs. However, this leaves the difficulty for the RSP of ensuring that TPMs interacting with the RSP have indeed been produced by a trusted manufacturer.
In principle, a platform could provide information or certificates to an RSP to authenticate itself. However, it is desirable for privacy reasons for the RSP to be unable to distinguish which TPM it is interacting with (i.e. desirably all that the RSP will be able to establish is that it is interacting with a bona fide TPM manufactured by a known—and trusted—manufacturer) such that the platform and/or user cannot be identified or otherwise distinguished from other users or platforms.
One approach to providing such an assurance to an RSP is to use a further third party, a Certificate Authority (CA), trusted by both the platform's owner and the RSP. The TPM manufacturer provides a unique endorsement key for the TPM and then certifies it. The CA then issues a certificate on a randomly chosen identity after verifying the manufacturer's certificate. It is then the CA's certificate that is used by the RSP to check the validity of the TPM—if the certificate is verified, the RSP will trust the TPM to be an authentic product of the trusted manufacturer because the RSP trusts the CA. If the RSP finds out something wrong with a particular certified identity, the RSP reports this to the CA and the CA puts the problem identity in a revocation list and then refuses to certify any new identity to this TPM. The CA may or may not maintain a list of the mapping between endorsement keys and corresponding certificates.
In this scheme the CA is a weak point in the system—it potentially possesses a mapping between a TPM's Endorsement Key and identities issued to that TPM (and probably that of a large number of TPMs). If the CA reneges on a promise not to maintain such a mapping, or if the CA is permitted to keep such mappings as long as they are confidential but the CA's database is compromised, it becomes possible to correlate the identities of all TPMs which have been certified by that CA.
This is addressed in the applicant's co-pending patent application (PDNO 200312183-3 WO Application No GB2004/002185], the contents of which are incorporated herein by reference. In the disclosed system, a TPM is assumed authentic if it can prove it has a pre-agreed secret. A TPM is able to prove its authenticity by providing a product derived as a direct proof from its secret. In this manner, an RSP obtaining the direct proof can determine the TPM has a legitimate secret, but cannot determine the secret itself. In order to permit revocation of a TPMs trusted status, an arrangement discussed in which TPMs provide the direct proof to a certification authority that in return provides a certificate. Details of certificates previously associated with TPMs that have subsequently been unable to provide a direct proof of their authenticity are held in a blacklist. In this manner, the direct proof is used to obtain a certificate from a CA which certificate is subsequently used for authentication with an RSP. A certificate provided by a TPM to an RSP must be cross-referenced with the blacklist when determining the authenticity of the TPM.
Whilst this arrangement enables a TPM to assure an RSP that it is the authentic product of a trusted manufacturer without trusting a third party such as a CA with attestation information given by a manufacturer to the TPM, it introduces an overhead to the RSP in having to check the blacklist for each TPM encountered and also reduces the level of anonymity provided to the TPM (although the TPM cannot be directly traced from the information provided to either the CA or the RSP, information provided by TPMs must be differentiable so that blacklisted TPMs can be identified).
It is desirable for the authenticity of a TPM to be provable whilst retaining as much anonymity to the TPM and its associated platform as possible. In addition, it is desirable for this to be done in such a way that the status of the TPM can be revoked without allowing RSPs to become aware of the attestation information given by a manufacturer to the TPM that it is interacting with at any given time. It is further desirable for the provision or revocation of a RPM's trusted status be performed with as little computational and communication overhead as possible with respect to the RPM(s) and other TPMs.